第26回 #ginzarb 参加レポート

丹内です。
掲題の通り、Ginza.rb 第26回 シングルページアプリケーションのためのRailsとJavaScript フレームワークに参加してきたので、レポートします。

会場に行くまで

会場の株式会社みんなのウェディングさんは築地駅の近くにあり、アクセスが良かったです。
また、オフィスもとても綺麗でした。
Ginza.rbでは参加前の自己紹介Pull Requestを出す文化なのですが、これを忘れていて、直前の駆け込みPRになってしまいました・・・

自己紹介

最初に自己紹介タイムです。
Pull Requestした自己紹介Markdownを映しながら、簡単に自己紹介をしていきました。 この自己紹介だけでも、最近の流行りや苦労している点が聞けて、非常に興味深いと思いました。
自己紹介を聞いている限り、「実際に触っている人が多いのはvue.js、調べている人が多いのはReact.JS」という印象です。

キーノート:Backbone, Chaplin, Marionette そして React - Quipper における Single Page Application 開発の変遷

@kyannyさんのトークです。
詳細は見出しリンク先のスライドをごらんください。
以下は私の印象に残った部分のレポートになります。

おさらい：なぜSPAなのか

webアプリをSPA化する動機についてのおさらいからスタートです。 レスポンスが遅くなるとユーザ体験に悪影響が出ます。スマフォのブラウザではより顕著です。
「このままだと遅くてどうしようもない」という段階になるとユーザ体験の向上を目的としたパフォーマンス対策をするわけですが、

• ネイティブアプリを書ける人を雇って作る
• Webアプリを書くエンジニアがネイティブアプリを書けるようになる

といった方針は、Webエンジニアが多いQuipperではコストが高いという判断が下ったそうで、対策としてwebアプリのSPA化に踏み切った経緯があったそうです。

つまり、「ネイティブアプリには及ばないが、このノロさなら我慢できる」「一番低コストで作れる・維持できる」という妥協案としてのSPA導入でした。

JSフレームワークの紹介

Backbone

最初に採用されたフレームワークです。
期待した通りのUIが作れましたが、コードベースは複雑になってしまったそうです。
曰く、「背骨ではなく、バラバラの骨。そのつなぎ方が分からないと歪になるのでは」とのことでした。

Chaplin

Backboneベースで、より制約が強いフレームワークです。Backboneの次に採用されました。
QuipperにJoinsいたBackbone経験者の方が「Backboneの弊害を解決するため、別のFWが必要」ということで導入が決定したそうです。 採用してみて分かった欠点は、Chaplinは「Chaplin開発者の独自エコシステムの1つ」なので、ユーザによるカスタマイズが難しい部分ということだったようです。 また、幾つか便利な機能があるのですが、それがアプリの性質と合致していないのも、イマイチの点だったようでした。
曰く、「便利な機能は、それが想定している先に到達すると足を引っ張る」とのことでした。

Marionette

Chaplinの次に導入されたフレームワークです。
クライアント環境の回線が遅いこともあって、Quipperアプリが動いていたHerokuの30秒制限に引っかかってしまい、改善を余儀なくされたところで、

• Chaplin開発者がたくさんのOSSを書いていたりして、メンテに不安な点があった
• ドキュメントが不足していたり、あまり良い話を聞かない
• 実際のところ、Chaplinに飽きていた

という点から、これらを解消すべく導入したのがMarionetteだったそうです。

導入してみて下記の利点があり、現在もMaripnetteが使われているそうです。

• DOMとregionが対応している機構が、SPAの作りやすさを実現している
• フロントエンドMVCのファイルをmodule単位でまとめられるディレクトリ構成をとれる

話を聞いてみると、確かにshow()をベースにした作り方は、イメージしやすかったです。

曰く、「フロントエンドやっているとリスク承知でレールを外れなければならない時があるが、そこでフレームワークの縛りが緩いと楽」とのことでした。

React

新機能実装の際、拡張ではなく新規に作って統合という判断が下され、一部で使われているそうです。

RailsとSPAの共存

RailsはAPIとして振る舞うようにするのが良いそうです。app/controllers以下はほぼJSON APIで、リソースは全部JSONで返します。
この場合CROSなどをしなくて良いのですが、最新のフロントエンド環境を利用できないデメリットがあります。 結論として、minifyやpackなど足回りを、Nodeではなくassetspipelineに任せるのが楽ということでした。

SPA向きのAPI設計と実装

Railsアプリ本来のscaffold的なRESTful APIは、SPAのバックエンドとしては向いていないとのことでした。いわゆる「1 Screen, 1 API Call」ではないので、画面表示までに複数のAPIへリクエストを出さなければならないのが、SPAには不向きです。
なので、SPA専用のAPIを1つ用意するのが良いのではないか、とのことでした。
この構成はNetflixが参考になるそうです。Netflixは特殊なクライアント(例えばPS3)専用のAPIがあり、その後ろに堅いRESTfulがあるそうです。

質疑応答

JS環境のテストツールやテスタビリティについて

以下のようなツールを利用しているそうです。

• Mocka
• Konacha
• Teaspoon
• Evergreen

Mocha以外は、私は始めて聞いたツールでした。

テスタビリティについては、Backbone系は「このviewがnewされたらこのイベントハンドラがはられていること」などをテストしやすいそうです。
Quipperではリアルタイム性のためPusherを使っているそうですが、このテストを書くのは難しいということでした。

テストの並列化

フロントエンドのテストはパラレルにしてないそうです。CircleCIではparallelism(課金)によってRSpecの実行を自動で分割してくれるそうですが、フロントエンドのテストは分割されないため、結局は1つのインスタンスでテストするのと同じ時間がかかるそうです。 テストの実行時間は、CIでは10min、ローカルでひと通り流すと20minかかるそうです。

フロントエンド環境で型が必要か

modelではやっぱり型がほしいとのことです。
TSも良いと思う反面、Quipper社内ではそのような動きはあまり無いようでした。

AltJSについて

「Coffeeは補助輪」というのが印象的でした(JSがわからないRailsプログラマがJSを書くときに使う)。
ただ、「Coffeeで大規模になった今、Human ReadableなJSにコンバートするのは難しい」とのことでした。

JSの管理

JSのライブラリ管理は、gemもあり、npmもあり、bowerもありと、カオスになっているようです。
プライベートリポジトリのbootstrapは、git submoduleで管理しているそうです。
フロントのビルド環境は「事故った時に痛い割には、うまく行ってもあまり嬉しくない」ということで後回しになりがちというのが、印象的でした。

振り返り

質疑応答が終わった後、振り返りが行われました。
まず、Ginza.rbへ初参加の人に感想を聞き、次にKPTにより改善アクションを出していました。
その後、次回のお題/日時まで決めきていて、このような工夫が、継続的で良いコミュニティを生むのだと思いました。

まとめ

実際に会場に来てトークを聞くことで、スライドには書いていない「なぜこうしたのか」といった、結論に至る過程を聞くことができ、勉強になりました。
ちょうどReactとRailsを使ったSPAを作りたいと思い手を動かしていたので、個人的には最高なタイミングでした。
次回のお題もWeb APIに関する内容で興味があるので、また参加したいです！